In a rapidly changing telecommunications marketplace, companies can capitalize on the growing opportunities by introducing value-added services to customers seeking more reliable and economical telecommunications services. The tremendous growth in network infrastructure and corresponding growth in Internet Protocol (IP) traffic has resulted in the use of IP as a platform for new telecommunications services that take advantage of voice and data convergence. Examples of new services include video communications, Voice over IP (VoIP), video/audio conferencing, video-on-demand, on-line gaming, etc.
Because of such growth, Quality-of-Service (QoS) is becoming increasingly important to ensure high-quality transport within the network infrastructure, which includes monitoring one or more of the following:                Service availability, such as the reliability of the user's connection to the Internet Service.        Delay (also called latency), such as the time interval between transmitting and receiving packets.        Delay variation or jitter, which refers to the variation in time duration between all packets in a stream taking the same route.        Throughput, which is the average or peak rate at which packets are transmitted.        Packet loss rate resulting from congestion that is the maximum rate at which packets can be discarded during transfer through a network.        
FIG. 1 shows an example of a packet-based telecommunication network 10, which in this case is an IP network. The IP network of a generic telecommunication Service Provider (SP) typically includes a backbone network 12 connecting together two or more access networks, such as shown at 14, 16. Access network 14 is generally made of layer 1- or layer 2-type access/aggregation nodes 20, connecting a number of subscribers 18. Through the above access network, a subscriber can communicate with other subscribers on the same access network or gain access to the backbone network for communications outside the local area. The subscribers 18 (also generically called “users” hereafter) can take a variety of forms including a single home user, a company with one or more networks, a generic network device (e.g. application or content server), etc. Likewise, access network 16 has subscribers 22 and an access node 24. The access/aggregation nodes 20, 24 may use different technologies to connect the subscribers, such as SDH/Sonet, WDM, Ethernet, Frame Relay, xDSL, etc. Additionally, the above access/aggregation nodes 20, 24 may be provided by different vendors. The access/aggregation nodes 20, 24 communicate with the backbone network 12 through edge routers 30. The backbone network 12 includes a plurality of core routers 32, for providing routing paths generally used in long-distance communication. Both edge and core routers are generally layer 3-type devices.
FIG. 1 is a simplified illustration wherein only a small number of edge routers 30 and core routers 32 are shown, but the backbone network is generally a nationwide network and may include many thousands of core and edge routers. Similarly, although only two access networks 14, 16 are shown, there generally are many access networks connected to the backbone 12 in the IP network 10.
There are a number of known techniques for handling QoS in an IP network IP networks are traditionally based on a best effort approach for delivery of packets, wherein all transmissions or “flows” across the network are treated independently of their characteristics (e.g., source/destination pair, application, etc.). But this solution is insufficient for real-time applications, such as remote video, multimedia conferencing, visualization, and virtual reality. Before such real-time applications can be broadly used, the Internet infrastructure has to evolve in order to support QoS functionality, which provides some control over the main quality parameters (such as throughput, end-to-end packet delays, jitter, etc.).
One proposed solution to this problem is the Integrated Services (IntServ) model, which uses a Resource Reservation Protocol (RSVP) to check and reserve the necessary resources along the path of IP nodes between the source and destination. However, this solution has both quality control problems and scaling issues. For example, one quality control problem is that the source computer can request directly to the IP nodes whatever resources it desires. As a result, a subscriber can take direct control of resource allocation over the ISP network. The RSVP protocol also has scaling issues because the routers must store state information for each flow. Thus, the amount of state information increases proportionally with the number of flows placing a huge storage and processing overhead on the routers.
Another solution is called Differentiated Services (DiffServ). DiffServ is based on a classification of the flows that enter the network. Based on that classification, each packet is marked with a code that defines the class to which it belongs. On each network node, a policy called PHB (Per Hop Behaviour) is defined for each class, specifying the treatment experienced by all packets belonging to that class that cross the node. In order to support QoS guarantees with DiffServ, it is necessary to guarantee that the total amount of traffic injected for each class does not exceed the available resources. As an extension to the basic DiffServ model, centralized agents called bandwidth brokers that receive user requests and that manage the allocation of network resources have been proposed. The bandwidth brokers authenticate the requestor's credentials, check the availability of network resources, update the resource databases, and configure the network nodes to setup the communication. Although the DiffServ solution solves some of the problems with scalability and performance, it is focused on solving problems for backbone networks, rather than access networks. Access networks present peculiar characteristics, as they may differ from backbone networks, in terms of topology and technology. As a result, the DiffServ solution with bandwidth brokers is not optimized for the resource modelling and admission control in access networks.
Moreover, access areas can be significantly different also from each other in terms of implementation technology (xDSL, ATM, GBE, etc.). Each implementation technology has its own characteristics, which make it difficult to create an architecture according to all the parameters necessary for admission control (bandwidth, interfaces, etc.). Additionally, the different technologies create problems tracking allocated and available resources. Unlike in a backbone network, configuration normally takes place on parameters more closely tied to physical aspects than to the TCP/IP world.
Another solution uses MPLS Traffic Engineering (MPLS-TE) techniques. These techniques expect that traffic routing on the network can be controlled by creating virtual circuits, known as TE-tunnels, and setting-up predetermined paths while taking into account any assigned bandwidth limitations. The allocation of resources needed to satisfy the QoS requirements is thus implicit in the creation of the TE-tunnels. Like the DiffServ solution, the MPLS-TE solution does not adapt well to access networks. Additionally, this solution works well for traffic transported on the TE tunnels, but it is ineffective for establishing guarantees for the remaining part of the traffic routed using the normal procedures provided by the IP protocol.
A specific solution, inspired to a DiffServ model with bandwidth brokers, called QMTool, is proposed in a paper called “On providing a Dynamic QoS Management system for IP Networks”, by L. Dimopoulou et al., Proceedings of 10th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2002), Split & Dubrovnik (Croatia), Ancona & Venice (Italy), Oct. 8-11, 2002, which describes a platform independent of the underlying technologies or vendor-specific equipment. A three-layer approach is described. The lower layer is responsible for the direct communication with managed objects (e.g. routers, workstations, servers). The second layer processes the data provided by the lower layer. Finally, the upper layer serves as a front-end tool facilitating the interaction with a network operator. A Resource Control Layer (RCL) is used as a distributed bandwidth broker and includes a Resource Control Agent (RCA), an Admission Control Agent (ACA) and the End-User Application Toolkit (EAT). The RCA is mainly responsible for the management of network resources within an administrative domain. The ACA is mainly responsible for user authentication and authorization, reservation handling, and flow admission control. The EAT forwards reservation requests from the users to the ACA.
The Applicant observes that, like the shortcomings of other QoS technologies, the QMTool does not provide admission control over the access networks. Instead the focus of admission control is only on the backbone network. However, as already described, management of backbone networks is very different from management of access networks, which can impact resource modelling and admission control.
The Applicant has thus noticed that prior art lacks a solution for allowing adequate QoS control over an end-to-end transmission in a packet-based telecommunications network. In particular, The Applicant has noticed that the prior art lacks an adequate solution that provides admission control covering both the backbone network and the access networks.